src/main/java/com/debatetimer/repository/customize/BellRepository.java (1)

6-9: 최소한의 Repository 인터페이스입니다.

현재 save 메소드만 정의되어 있어 요구사항에 맞습니다. 향후 벨 조회 기능이 필요할 경우 추가 메소드를 고려해보세요.

src/main/resources/db/migration/V9__add_bell_table.sql (1)

1-13: 데이터베이스 스키마가 올바르게 정의되었습니다.

테이블 구조와 외래키 제약조건이 적절하게 설정되었습니다. 다만 time과 count 컬럼에 bigint를 사용했는데, 일반적인 사용 범위를 고려하면 int 타입으로도 충분할 것 같습니다.

-    time    bigint       not null,
-    count       bigint not null,
+    time    int       not null,
+    count       int not null,

src/main/java/com/debatetimer/entity/customize/Bell.java (2)

43-47: 벨 시간 검증 로직을 개선하세요.

현재 time >= 0을 허용하고 있지만, 0초에 벨이 울리는 것이 의미가 있는지 검토가 필요합니다. 일반적으로 벨은 양수 시간에 울리는 것이 자연스럽습니다.

다음과 같이 수정을 고려해보세요:

 private void validateTime(int time) {
-    if (time < 0) {
+    if (time <= 0) {
         throw new DTClientErrorException(ClientErrorCode.INVALID_BELL_TIME);
     }
 }

---

31-32: 필드 접근 제한자를 고려하세요.

JPA 엔티티에서 필드를 private으로 선언하는 것이 캡슐화 관점에서 더 좋습니다.

-    private int time;
-    private int count;
+    private final int time;
+    private final int count;

또는 최소한:

-    private int time;
-    private int count;
+    private final int time;
+    private final int count;

src/main/java/com/debatetimer/service/customize/CustomizeService.java (1)

104-104: 하드코딩된 값들을 상수로 정의하세요.

벨 횟수(1, 2)와 경고 시간(30)이 하드코딩되어 있습니다. 이를 상수로 정의하여 유지보수성을 높이세요.

+private static final int WARNING_BELL_COUNT = 1;
+private static final int FINISH_BELL_COUNT = 2;
+private static final int WARNING_BELL_OFFSET_SECONDS = 30;

 // 사용 시:
-new Bell(timeBox, timeBox.getTime(), 2)
+new Bell(timeBox, timeBox.getTime(), FINISH_BELL_COUNT)

-new Bell(timeBox, timeBox.getTime() - 30, 1)
+new Bell(timeBox, timeBox.getTime() - WARNING_BELL_OFFSET_SECONDS, WARNING_BELL_COUNT)

Also applies to: 114-114

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

src/main/java/com/debatetimer/service/customize/CustomizeService.java (1)

109-111: 응답 구성에서 음수 시간 검증이 누락되었습니다.

getCustomizeTableResponse 메서드에서 경고 벨의 시간을 계산할 때 음수 검증이 없습니다. saveBell 메서드에서는 30초 이상인 경우만 처리하도록 필터링하고 있지만, 응답 구성에서는 동일한 검증이 없어 일관성 문제가 있습니다.

다음과 같이 수정하세요:

 if (savedTable.isWarningBell()) {
-    bell.add(new BellResponse(timeBox.getTime() - 30, 1));
+    if (timeBox.getTime() >= 30) {
+        bell.add(new BellResponse(timeBox.getTime() - 30, 1));
+    }
 }

src/main/java/com/debatetimer/service/customize/CustomizeService.java (1)

99-123: 메서드 복잡성 개선이 필요합니다.

getCustomizeTableResponse 메서드가 여러 책임을 가지고 있어 단일 책임 원칙을 위반하고 있습니다. 벨 정보 구성 로직을 별도 메서드로 분리하는 것을 권장합니다.

다음과 같이 벨 정보 구성 로직을 분리할 수 있습니다:

private List<BellResponse> createBellResponses(CustomizeTimeBox timeBox, CustomizeTableEntity table) {
    if (!timeBox.getBoxType().isNotTimeBased() || (!table.isFinishBell() && !table.isWarningBell())) {
        return null;
    }
    
    List<BellResponse> bells = new ArrayList<>();
    if (table.isWarningBell() && timeBox.getTime() >= 30) {
        bells.add(new BellResponse(timeBox.getTime() - 30, 1));
    }
    if (table.isFinishBell()) {
        bells.add(new BellResponse(timeBox.getTime(), 2));
    }
    return bells;
}

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

src/main/java/com/debatetimer/dto/customize/request/CustomizeTimeBoxCreateRequest.java (2)

39-46: 벨 데이터 매핑 로직 추가 필요

CustomizeTimeBoxCreateRequest.toTimeBox 메서드에서 요청된 bell 필드를 무시하고 있으며, 서비스 레이어에서도 BellRequest를 처리하는 로직이 전혀 없습니다.
아래 항목을 반영해 수정이 필요합니다:

• CustomizeTimeBoxCreateRequest.toTimeBox에서 List<BellRequest> bell을 도메인 객체(CustomizeTimeBox)에 매핑하도록 변경
• CustomizeService.save/updateTable 등에서 DTO의 BellRequest를 Bell 엔티티로 변환 후 저장하거나, CustomizeTimeBox 생성 직후 Bell 저장 로직 추가

예시(diff):

     public CustomizeTimeBox toTimeBox(CustomizeTable customizeTable, int sequence) {
-        if (boxType.isTimeBased()) {
-            return new CustomizeTimeBox(new CustomizeTableEntity(customizeTable), sequence, stance, speechType,
-                    boxType, timePerTeam, timePerSpeaking, speaker);
-        }
-        return new CustomizeTimeBox(new CustomizeTableEntity(customizeTable), sequence, stance, speechType, boxType,
-                time, speaker);
+        CustomizeTimeBox box;
+        if (boxType.isTimeBased()) {
+            box = new CustomizeTimeBox(new CustomizeTableEntity(customizeTable), sequence,
+                    stance, speechType, boxType, timePerTeam, timePerSpeaking, speaker);
+        } else {
+            box = new CustomizeTimeBox(new CustomizeTableEntity(customizeTable), sequence,
+                    stance, speechType, boxType, time, speaker);
+        }
+        // BellRequest → Bell 도메인 매핑
+        if (bell != null) {
+            bell.forEach(b -> box.addBell(new BellEntity(box, b.time(), b.count())));
+        }
+        return box;
     }

---

39-46: toTimeBox 메서드에서 벨 데이터 처리 누락

새로 추가된 bell 필드가 toTimeBox 메서드에서 처리되지 않고 있습니다. 이로 인해 벨 데이터가 엔티티 변환 과정에서 손실될 수 있습니다.

 public CustomizeTimeBox toTimeBox(CustomizeTable customizeTable, int sequence) {
     if (boxType.isTimeBased()) {
         return new CustomizeTimeBox(new CustomizeTableEntity(customizeTable), sequence, stance, speechType,
-                boxType, timePerTeam, timePerSpeaking, speaker);
+                boxType, timePerTeam, timePerSpeaking, speaker, bell);
     }
     return new CustomizeTimeBox(new CustomizeTableEntity(customizeTable), sequence, stance, speechType, boxType,
-            time, speaker);
+            time, speaker, bell);
 }

src/test/java/com/debatetimer/service/customize/CustomizeServiceTest.java (3)

109-111: 다른 테스트 메서드에서도 동일한 테스트 데이터 불일치가 발생합니다.

업데이트 테스트에서도 동일한 문제가 반복되고 있습니다.

---

125-129: 업데이트 테스트에서도 벨 검증 로직이 부정확합니다.

저장 테스트와 동일한 문제가 발생하고 있습니다.

---

205-207: 마지막 테스트 케이스에서도 동일한 테스트 데이터 문제가 있습니다.

모든 테스트에서 일관된 벨 설정을 사용하거나, 각 테스트의 목적에 맞는 검증 로직을 구현해야 합니다.

src/test/java/com/debatetimer/service/customize/CustomizeServiceTest.java (4)

57-61: 벨 검증 로직 개선

각 타임박스에 대해 정확히 2개의 벨이 있는지 검증하는 로직이 추가되었습니다. 하지만 하드코딩된 값 대신 실제 입력 데이터를 기반으로 검증하는 것이 더 나을 것 같습니다.

다음과 같이 개선할 수 있습니다:

() -> {
    for (CustomizeTimeBox timeBox : foundTimeBoxes) {
-       assertThat(bellRepository.findByCustomizeTimeBox(timeBox)).hasSize(2);
+       // 첫 번째 타임박스: 1개 벨, 두 번째 타임박스: 2개 벨
+       int expectedBellCount = timeBox.getSequence() == 1 ? 1 : 2;
+       assertThat(bellRepository.findByCustomizeTimeBox(timeBox)).hasSize(expectedBellCount);
    }
}

---

125-129: 일관된 벨 검증 로직

업데이트 테스트에서도 동일한 벨 검증 로직이 사용되고 있습니다. 앞서 언급한 개선사항이 여기에도 적용될 수 있습니다.

---

144-146: 예외 테스트 케이스에서도 동일한 테스트 데이터를 사용하고 있습니다.

예외 상황을 테스트하는 케이스에서도 일관성 있는 테스트 데이터를 사용하는 것이 좋습니다.

---

164-166: 동시성 테스트에서도 동일한 패턴이 반복됩니다.

테스트 데이터의 일관성을 위해 모든 테스트에서 동일한 벨 설정 패턴을 사용하는 것을 고려해보세요.

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

src/main/java/com/debatetimer/service/customize/CustomizeServiceV2.java (1)

112-124: 타임 기반 박스에 대한 벨 요청 처리 개선 제안

타임 기반 박스의 경우 bellRequests 파라미터가 무시됩니다. API 일관성을 위한 설계로 보이나, 명확성을 위해 다음을 고려해보세요:

• 문서화 추가로 타임 기반 박스에서는 벨이 무시됨을 명시
• 또는 검증 로직 추가로 타임 기반 박스에 벨 요청이 있을 경우 경고

 private CustomizeTimeBoxResponse createTimeBoxResponse(List<BellRequest> bellRequests, CustomizeTimeBox timeBox) {
     if (timeBox.getBoxType().isTimeBased()) {
+        // 타임 기반 박스는 벨을 지원하지 않음
         return new CustomizeTimeBoxResponse(timeBox, null);
     }

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

src/main/java/com/debatetimer/repository/customize/BellRepository.java (1)

14-14: 성능 최적화를 위한 배치 삭제 고려해보세요.

과거 코멘트에서 언급된 대로, 현재 deleteAllByCustomizeTimeBoxIn 메서드는 영속성 컨텍스트를 통해 동작하여 CustomizeTimeBox 수만큼 개별 DELETE 쿼리가 실행됩니다. 대량 데이터 처리 시 성능 이슈가 발생할 수 있습니다.

다음과 같은 대안을 고려해보세요:

+@Modifying
+@Query("DELETE FROM BellEntity b WHERE b.customizeTimeBox IN :customizeTimeBoxes")
+void deleteAllByCustomizeTimeBoxInBatch(List<CustomizeTimeBox> customizeTimeBoxes);

또는 JPA의 배치 삭제 기능 활용:

+void deleteAllByCustomizeTimeBoxIn(List<CustomizeTimeBox> customizeTimeBoxes);
+
+@Modifying
+@Query("DELETE FROM BellEntity b WHERE b.customizeTimeBox.id IN :timeBoxIds")
+void deleteAllByCustomizeTimeBoxIds(List<Long> timeBoxIds);

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro